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There are situations in programming where some dynamic typing is needed, even 
in the presence of advanced static type systems. We investigate the interplay 
of dynamic types with other advanced type constructions, discussing their inte- 
gration into languages with explicit polymorphism (in the style of system F), 
implicit polymorphism (in the style of ML), abstract data types, and subtyping. 
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1 Introduction 



Dynamic types are sometimes used to palliate deficiencies in languages with 
static type systems. They can be used instead of polymorphic types, for ex- 
ample, to build heterogeneous lists; they are also exploited to simulate object- 
oriented techniques safely in languages that lack them, as when emulating meth- 
ods with procedures. But dynamic types are of independent value, even when 
polymorphic types and objects are available. They provide a solution to a 
kind of computational incompleteness inherent to statically-typed languages, 
offering, for example, storage of persistent data, inter-process communication, 
type-dependent functions such as print, and the eval function. 

Hence, there are situations in programming where one would like to use 
dynamic types even in the presence of advanced static type systems. In this 
paper we investigate the integration of dynamic types into languages with ex- 
plicit polymorphism (in the style of system F [10]), implicit polymorphism (in 
the style of ML [16]), abstract data types, and subtyping. Our study extends 
earlier work [1], but keeps the same general approach and the same basic lan- 
guage constructs: dynamic, for tagging a value with its type, and typecase, for 
comparing a type tag with a pattern and branching according to whether they 
match. 

The interaction of polymorphism and dynamic types gives rise to problems 
in binding type variables. We find that these problems can be more clearly 
addressed in languages with explicit polymorphism. Even then, we encounter 
some perplexing difficulties (as indicated in [1]). In particular, there is no unique 
way to match the type tag of a dynamic value with a typecase pattern. Our 
solution consists in constraining the syntax of typecase patterns, thus providing 
static guarantees of unique solutions. The examples we have examined so far 
suggest that our restriction is not an impediment in practice. 

Drawing from the experience with explicit polymorphism, we consider lan- 
guages with implicit polymorphism in the ML style. The same ideas can be 
used, with some interesting twists. In particular, we are led to introduce tuple 
variables, which stand for tuples of type variables. 

The treatment of abstract data types does not present any new typing or 
matching difficulties. Instead, it raises an interesting question: whether the type 
tag of a dynamically typed value should be matched abstractly or concretely 
(that is, using knowledge of the value's actual run-time type). We explore the 
consequences of both choices. 

Subtyping is exploited in combination with dynamic types in languages with 
restricted typecase patterns, such as Simula-67 [3] and Modula-3 [8]. There, a 
tag matches a pattern if it is a subtype of the pattern. This sort of matching does 
not work out well with more general typecase patterns. We find it preferable to 
match type tags against patterns exactly, and then perform explicitly prescribed 
subtype tests. 

In addition to [1], several recent studies consider languages with dynamic 
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types [12, 14, 21]. The work most relevant to ours is that of Leroy and Mauny, 
who define and investigate two extensions of ML with dynamic types. We 
compare their designs to ours in section 4. 

Section 2 is a brief review of dynamic typing in simply typed languages, based 
on [1]. Section 3 considers the addition of dynamic typing to a language with 
explicit polymorphism [10]. Section 4 then deals with a language with implicit 
polymorphism. Sections 5 and 6 discuss abstract data types and subtyping, 
respectively. We conclude in section 7. 



2 Review 

The integration of static and dynamic typing is fairly straightforward for mono- 
morphic languages. The simplest approach introduces a new base type Dynamic 
along with a dynamic expression for constructing values of type Dynamic (infor- 
mally called "dynamics") and a typecase expression for inspecting them. The 
typechecking rules for these expressions are: 

T \- aeT 

r h dynamic(a:T) G Dynamic 

r h rfe Dynamic T,x:P \- b^T T h c £ T 

r h typecase d of {x:P) h else c ^ T ^ 

The phrases {x:P) and else are branch guards; _P is a pattern — here, just a 
monomorphic type; h and c are branch bodies. For notational simplicity, we have 
considered only typecase expressions with exactly one guarded branch and an 
else clause; a typecase involving several patterns can be seen as syntactic 
sugar for several nested instances of the single-pattern typecase. 

In the most direct implementation, the semantics of a dynamic is a pair 
consisting of a value and its type. The semantics of typecase d of (x:A) b 
else e is then: break d into a value c and a type C, and if C matches A then 
bind X to c and execute b, otherwise execute e. In the simplest version of this 
semantics, C matches A if they are identical; in languages with subtyping, it is 
common to allow C to be a subtype of A instead. 

Constructs analogous to dynamic and typecase have appeared in a number 
of languages, including Simula-67 [3], CLU [15], Cedar/Mesa [13], Amber [4], 
Modula-2-|- [20], Oberon [23], and Modula-3 [8]. These constructs have sur- 
prising expressive power; for example, fixpoint operators can already be defined 
at every type in a simply typed lambda-calculus extended with Dynamic [1]. 
Important applications of dynamics include persistence and inter-address-space 
communication. For example, the following primitives might provide input and 
output of a dynamic value from and to a stream: 

extern G Writer xDynamic—S-Unit 
intern G Reader— ^Dynamic 



(Dyn-I) 



2 



Moreover, dynamics can be used to give a type for an eval primitive [11, 18]: 

eval G Exp— ^Dynamic 

We obtain a much more expressive system by allowing typecase guards 
to contain pattern variables. For example, the following function takes two 
dynamics and attempts to apply the contents of the first (after checking that it 
is of functional type) to the contents of the second: 

dynApply = 

A(df :Dynamic) A(da:Dynamic) 
typecase df of 
{U,V} (f:U-^V) 
typecase da of 
{} (a:U) 

dynamic(f (a) :V) 
else . . . 
else . . . 

Here U and V are pattern variables introduced by the first guard. In this example, 
if the arguments are: 

df = dynamic((A(x:Int)x+2) :Int-Mnt) 
da = dynamic (5 : Int) 

then the typecase guards match as follows: 

Tag: Int-Mnt 

Pattern: U-^V 

Result: {U = Int, V = Int} 

Tag: Int 
Pattern: Int 
Result: {} 

and the result of dynApply is dynamic(7 : Int). 

A similar example is the dynamic-composition function, which accepts two 
dynamics as arguments and attempts to construct a dynamic containing their 
functional composition: 

dynCompose = 

A (df : Dynamic) A (dg: Dynamic) 
typecase df of 
{U,V} (f:U-^V) 
typecase dg of 
{¥} (g:¥^U) 

dynamic (f o g :¥—;>¥) 
else . . . 
else . . . 
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3 Explicit Polymorphism 



This formulation of dynamic types may be carried over almost unchanged to 
languages based on explicit polymorphism [10, 19]. For example, the following 
function checks that its argument df contains a polymorphic function f taking 
lists to lists. It then creates a new polymorphic function that accepts a type 
and a list x of values of that type, instantiates f appropriately, and applies f to 
the reverse of x: 

A(df : Dynamic) 
typecase df of 

{} (f:V(Z) List(Z)-^List(Z)) 

A(Y) A(x:List(Y)) f [Y] (reverse [Y] (x) ) 
else A(Y) A(x:List(Y)) x 

Here List and reverse have the obvious meanings; they are not primitives of 
the language treated below, but can be encoded. The type abstraction operator 
is written A. Type application is written with square brackets. The types of 
polymorphic functions begin with V. For example, V(X)X— S-X is the type of the 
polymorphic identity function, A(X) A(x : X) x. 

3.1 Higher-order pattern variables 

First-order pattern variables, by themselves, do not appear to give us sufficient 
expressive power in matching against polymorphic types. For example, we might 
like to generalize the dynamic-application example from section 2 so that it can 
accept a polymorphic function and instantiate it appropriately before applying 
it: 

dynApply2try = 

A(df :Dynamic) A(da:Dynamic) 
typecase df of 

{} (f :V(Z)...^...) 
typecase da of 
{¥} (a:¥) 

dynamic (f [¥] (a) : ...) 
else . . . 
else dynApply (df ) (da) 

But there is no single expression we can fill in for the domain of f that will 
make dynApply2try apply to both 

df = dynamic (A(Z) A(x:ZxZ) <snd(x) ,f st(x)>: ...) 
da = dynamic (<3,4>: ...) 

and 
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df = dynamic((A(Z) A(x:Z-^Z) x): ...) 
da = dynamic ( (A(x : Int) x) : ...) 

In the former case, the expected type for f is V(X) (XxX)— ;>(XxX) ; in the latter 
case, it is V(X) (X— S-X)— ;>(X— S-X) . These two types are incompatible. 

Thus we are led to introducing higher-order pattern variables. A higher- 
order pattern variable ranges over pattern contexts — patterns abstracted with 
respect to some collection of type variables. With higher-order pattern variables, 
we can express polymorphic dynamic application: 

dynApply2 = 

A(df :Dynamic) A(da:Dynamic) 
typecase df of 

{F,G} (f :V(Z)F(Z)^G(Z)) 
typecase da of 
{¥} (a:F(¥)) 

dynamic(f [¥] (a) :G(¥)) 
else . . . 
else dynApply (df ) (da) 

For example, if 

df = dynamic(id:V(X)X-^X) 
da = dynamic (3 : Int) 

then the typecase expressions match as follows: 

Tag: V(X)X^X 
Pattern: V(Z)F(Z)-^G(Z) 
Result: {F = A(X) X, G = A(X) X} 

Tag: Int 

Pattern: F(¥) (which reduces to ¥) 
Result: {¥ = Int} 

and the result of the application 

dynApply2(df )(da) 

is 

dynamic(id[lnt](3) : Int) 

Following standard notational conventions, we write A(X)X for the identity func- 
tion on types, reserving lowercase letters for expressions at the level of terms 
and A for term-level abstractions. 
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It is now easy to deal with the two inputs given above. If 

df = dynamic (A(Z) A(x:ZxZ) <snd(x) ,f st(x)>: 

V(X)(XxX)-^(XxX))) 
da = dynamic(<3 ,4> : Intx Int) 

then the match is: 

Tag: V(X) (XxX)-^(XxX) 

Pattern: V(Z)F(Z)-^G(Z) 

Result: {F = A(X) XxX, G = A(X) XxX} 



Tag: Int 

Pattern: F(¥) (which reduces to ¥x¥) 
Result: {¥ = Intx Int} 

If 

df = dynamic((A(Z) A(x:Z-^Z) x) : V(X) (X-^X)-^(X-^X) ) 
da = dynamic ( (A(x : Int ) x) : Int— S-Int) 

then the match is: 

Tag: V(X)(X^X)^(X^X) 

Pattern: V(Z)F(Z)-^G(Z) 

Result: {F = A(X) X-^X, G = A(X) X-^X} 



Tag: Int 

Pattern: F(¥) (which reduces to ¥—;>¥) 
Result: {¥ = Int-Mnt} 



3.2 Syntax 

We now present dynamic types in the context of a second-order polymorphic 
A-calculus, system F. The syntax of F with type Dynamic (including some 
third-order constructs used in patterns) is given in Figure 1. In examples we 
also use base types, cartesian products, and lists in types and patterns, but we 
omit these in the formal treatment. 

We regard as identical any pair of formulas that differ only in the names 
of bound variables. For brevity, we sometimes omit kinding declarations and 
empty pattern- variable bindings. Also, it is technically convenient to write the 
pattern variables bound by a typecase expression as a syntactic part of the 
pattern, rather than putting them in front of the guard as we have done in 
the examples. Thus, typecase el of {V}(x:T)e2 else e3 should be read 
formally as typecase el of (x: {V:Type}T)e2 else e3. 
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K 


■■= Type 


the kind of types 


T 


:= Z 






1 F 


first-order pattern variable 






function types 




V(Z : A') T 


quantified types 




F{T") {n > 0) 


application of a type operator 




1 Dynamic 


the dynamic type 


J 


:= K 


kind of simple pattern types 




1 K"-^K {n > 0) 


functional kinds 


P 


:= {Fi : Ji, . . . , Fn : Jn}T 


patterns 


a 


:= X 


variables 




1 X{x : T) a 


abstraction 




1 '^i'^) 


application 




X{Z : K) a 


type abstraction 




1 «m 


type application 




1 dynamic(a : T) 


tagging 




1 typecase a of (x : P) a else a 


tag matching 



Figure 1: Syntax for system F with Dynamic 



3.3 Tag closure 

One critical design decision for a programming language with type Dynamic 
is the question of whether type tags must be closed (except for occurrences 
of pattern variables), or whether they may mention universally bound type 
variables from the surrounding context. 

In the simplest scenario, dynamic (a: A) is legal only when A is a closed type. 
(The type A may be polymorphic, of course, so long as all the type variables it 
mentions are also bound within A; for example, V(Z) Z is a legal tag.) Similarly, 
we would require that the guard in a typecase expression be a closed type. 

If the closure restriction is not instituted, then types must actually be passed 
as arguments to polymorphic functions at run time, so that code can be compiled 
for expressions like: 

A(X) A(x:X) dynamic(<x,x>:XxX) 

where the type X x X must be generated at run time. For languages where 
type information is not retained at run time, such as ML, the closure restriction 
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becomes essential (see section 4). For now, we consider the unrestricted case, 
where tags may contain free type variables. 

3.4 Definiteness and matching 

When pattern variables may range over functions on types, there is in general 
no guarantee of unique matches of patterns against tags. For example, when 
the pattern F(lnt) is matched against the tag Bool, the pattern variable F is 
forced to be A(X)Bool. But when the same pattern is matched against the tag 
Int, we find that F can be either A(X)X or A(X)Int. There is no reasonable 
way to choose. Worse yet, consider F(¥) or F(¥— S-Int) for a pattern variable ¥. 
Two sorts of solutions come to mind: 

• At run time, we may look for matches and fail if none or more than one 
exist. Unfortunately, failures could be somewhat unpredictable. 

• At compile time, we may allow only patterns that match each tag in 
at most one way. This condition on patterns is called defimteness in a 
preliminary version of this work [2] . As definiteness seems hard to decide 
at compile time, an approximation to definiteness may be used instead. 

As in [2], we choose a compile-time solution. We propose a condition on patterns 
sufficient to guarantee definiteness ((1) and (2), below), in combination with 
an appropriate definition of matching ((3), below). This condition is more 
restrictive than that of [2] , and in some cases it may entail some code duplication. 
On the other hand, it is easier to describe, it suffices for our examples, and in 
general it does not seem to affect expressiveness. 
Our condition on patterns is: 

1. each pattern variable introduced in a pattern is used in the same pattern; 

2. in each of these uses, the arguments of the pattern variable are distinct 
type variables bound in the same pattern (not pattern variables). 

Note that as far as inner typecase expressions are concerned, pattern variables 
of outer typecase expressions are just constants, and they may appear in any 
positions where constants may appear. 
For example, we allow: 

{F : Type-^Type}V(Z) F(Z) 

{F : Type^Type}V(Z) H(F(Z)) 

{G : Type x Type-^Type}V(Z) V(¥) G(¥, Z) 

(where H is a pattern variable of arity 1 introduced by an enclosing typecase). 
But we do not allow: 

{F : Type^Type}F(lnt) 

{F : Type^Type, H : Type^Type}V(Z) F(H(Z)) 
{G : Type x Type^Type}V(Z) G(Z, Z) 
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because, according to requirement (2), F must be applied to a type variable 
rather than to Int or to H(Z), and G must be applied to two distinct type 
variables rather than to Z twice. 

At run time, we must solve the problem of matching a tag against a pattern. 
The cases where the pattern's outermost construct is a type variable, — or V are 
all evident. Hence, the problem of matching a tag against a pattern is reduced 
to matching subproblems of the form F(Xj^, . . . , Xj^) = A, where F is a pattern 
variable introduced in the pattern, Xj^, . . . , Xj^ are distinct type variables, and A 
is a subexpression of the tag. We require: 

3. the free type variables of a tag subexpression matching a pattern variable 
are exactly the arguments to the pattern variable 

or, in this instance, Xj^, . . . , Xj^ are the free type variables of A. If this holds, we 
take F = A(Xj^) . . . A(Xjj) A as the solution for the subproblem. This solution is 
evidently unique, and thus definiteness is guaranteed. Moreover, requirement (3) 
implies that the function A(Xj^) . . . A(Xjj) A has the desirable properties of being 
closed and of using all of its arguments. 
For example, we obtain a success with 

Tag: V(Z) V(¥) Z^(Z^Z) 

Pattern: {F : Type-^Type}V(Z) V(¥) F(Z) 

Result: {F = A(X) X-^(X-^X)} 

but failures with 

Tag: V(Z) V(¥) Z-^(¥-^¥) 

Pattern: {F : Type-^Type}V(Z) V(¥) F(Z) 

Result: failure 

and 

Tag: V(Z) V(¥) Int-^(lnt-Mnt) 
Pattern: {F : Type-^Type}V(Z) V(¥) F(Z) 
Result: failure 

In the second example, ¥ is a free variable of the tag subexpression Z— ;>(¥—;>¥) 
but not an argument in F(Z). Requirement (3) prevents the escape of ¥ from the 
scope of its binder. In the third example, Z is an argument in F(Z) but does not 
occur in the tag subexpression Int— ;>(lnt— S-Int). Requirement (3) guarantees 
that later, successful matches instantiate all new pattern variables: if F were 
allowed not to use its argument Z, a later pattern 

{V : Type}F(V) 

might succeed with V undetermined. 

The cost of our requirements may be some inconvenience. We adopt them 
for the sake of soundness and simplicity. 
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4 Implicit Polymorphism 



In this section we investigate dynamics in an implicitly typed language, the core 
language of ML. 

The general treatment of dynamics for explicitly typed languages can be 
applied directly to ML, thus providing the language with explicitly tagged dy- 
namics. In this extension of ML, types can still be inferred for all constructs 
except dynamics; the user needs to provide type information only when creating 
or inspecting dynamics. For instance, consider the following program: 

twice = dynamic(A(f) A(x) f(f x) : V(Z) (Z-^Z)-^(Z-^Z) ) 

To verify its correctness, we first infer the type scheme V(Z) (Z— S-Z)— ;>(Z— S-Z) 
for A(f) A(x) f(f x) as if it were to be let-bound. Then we check that this 
type scheme has no free variables and that it is more general than the required 
tag V(Z) (Z— S-Z)— ;>(Z— S-Z) . Similarly, when a typecase succeeds, the extracted 
value is given the type scheme of its tag as if it had been let-bound. That is, 
an instance of the value can be used with different instances of the tag as in: 

foo = A(df) 

typecase df of 

(f :V(Z)(Z-^Z)-^(Z-^Z)) <f succ, f not> 
else . . . 

where succ is the successor function on integers, and not is the negation function 
on booleans. 

This solution is adequate. However, it seems to go against the spirit of ML 
in several respects, as we discuss next. 

4.1 Implicit tagging 

The solution just sketched requires explicit tags in dynamic expressions. Since 
the ML typechecker can infer most general types for expressions, one would 
expect it to tag dynamics with their principal types. For instance, the user 
should be able to write: 

twice = dynamic(A(f) A(x) f(f x)) 

and expect that the dynamic will be tagged with V(Z) (Z— S-Z)— ;>(Z— S-Z) . 

If types are not to be passed as arguments to polymorphic functions at run 
time, the tags of dynamics must be closed (see section 3.3). This restriction 
creates difficulties for the implicit-tagging approach: a program like 

A(x) dynamic(x) 

will fail to have a principal type. It will therefore simplify matters to assume 
that explicit tags are given in dynamic expressions. An alternative is discussed 
m [2]. 
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4.2 Tag instantiation and tuple variables 

The tag of apply: 

apply = dynamic(A(f) A(x) f x: V(X,Y) (X-^Y)-^(X-^Y) ) 

is equivalent to V(Y,X) (X— S-Y)— ;>(X— S-Y) , and an ML programmer would proba- 
bly view the order of quantifiers as unimportant. In addition, the tag is more 
general than the pattern in the function f oo; hence an ML programmer would 
probably expect the tag and the pattern to match when apply is passed to f oo. 
In general, it seems reasonable to ignore the order of quantifiers in a tag, and 
to let a tag match a pattern if any instance of the tag does. This principle is 
called tag mstantmtton. 

Tag instantiation and second-order pattern variables do not fit smoothly 
together. The difficulty comes from the combination of two features: 

• Second-order pattern variables may depend on universal variables, as in 
the pattern {F} (f : V(Z)F(Z)-^Z) . 

• Tag instantiation requires that if a typecase succeeds, then it also suc- 
ceeds for a dynamic with an argument that has a more general tag. 
The tag V(Z) (ZxZ)— S-Z matches the previous pattern; so should the tag 
V(X,Y) (XxY)— S-X. But F is not supposed to depend on two variables. 

Because of tag instantiation, polymorphic pattern variables may always depend 
on more variables than the ones explicitly mentioned. We deal with this possi- 
bility by introducing tuple variables, which stand for tuples of variables. The 
tuple variable in a pattern will be dynamically instantiated to the tuple of all 
variables of the tag not matched by other variables of the pattern. For example, 
using a tuple variable U, the pattern {F} (f : V(Z) F(Z)— S-Z) should be written 
{F} (f : V(U,Z) F(U,Z)^Z). 

Tuple variables bound in different patterns may be instantiated to tuples 
with different numbers of variables. Because of such size considerations, it is 
not always possible to use a tuple variable as argument to an operator, since 
this operator may expect an argument of different size. We introduce a simple 
system of arities in order to guarantee that type expressions are well formed. 
Formally, our example pattern should now be written: 

{tt : Tuple, F : tt Type Type} (f : V(U : tt, Z : Type) F(U, Z)-^Z) 

The arity variable tt is to be bound at run time to the size of the tuple assigned 
to the tuple variable U. However, it is not necessary to write all the arities in 
programs since a typechecker can easily infer them. 

In the following examples, we write Uj^ for the i-th component of tuple 
variable U. 

Tag: V(Z) (ZxZ)^Z 

Pattern: {7r,F} (f : V(U : tt, Z) F(U, Z)-^Z) 

Result: {tt = 0, F = A(U, Z) ZxZ} 
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K 


:= TT 




arity variables 




1 Type 




sort of types 


J 


:= K 








1 K X Type"— S-A' 






T 


:= Z 




type variables 




1 F 




first-order pattern variables 




1 Dynamic 
















F{T") {n > 0) 




application of a pattern operator 


S 


:= V(Zi : Ki, . . .,Z„ 


: Kn) T 


type schemes 


P 


:= {Tr,Fi : Ji,...,F„ 


■■ Jn} S 


patterns 


a 


:= X 








1 A(a;) a 








1 a a 








1 let X = a in a 








1 dynamic(a : 5) 








1 typecase a of (x : P) a 


3lse a 




Figure 


2: Syntax for ML with Dynamic 


Here the tuple arity is zero, thus F does not depend on U. 




Tag: V(X,Y)(X 


><Y)-^X 






Pattern: {tt,?} (f 


: V(U : TT, 


Z) F(U, Z)-^Z) 




Result: {tt = 1, F 


= A(U, Z 


) ZxUi} 




Tag: V(X,Y)(X 


><Y)-^X 






Pattern: {7r,F,G} 


(f : V(U : 


Tr,Z) F(U)^G(U)) 



Result: {tt = 2, F = A(U) V^xV2, G = A(U) U^} 



4.3 A language 

We briefiy consider a language with explicit tagging of dynamics and with tuple 
variables for tag instantiation. The syntax of the language is given in Figure 2. 

Typechecking for this language is similar to typechecking for ML with local 
type declarations and type constraints. In addition to typechecking the core 
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language, the well-formedness of type expressions and the correct scoping of 
type symbols must also be checked. 

The matching algorithm is slightly complicated by tag instantiation and the 
use of tuple variables. As in the explicit case, we stipulate that fresh pattern 
variables can be applied only to distinct universally quantified variables. We 
also require that there be at most one universal tuple variable per pattern, 
and that its arity be given by the unique fresh arity variable introduced in 
the pattern. With these restrictions, matching becomes a simple extension of 
first-order unification with restricted type operators; we omit the details. 

4.4 Related work 

The work on dynamic typing most closely related to ours is that of Leroy and 
Mauny [14]. Their dynamics without pattern variables have been implemented 
in the CAML language [22]. Our work can be seen as an extension of their 
system with "mixed quantification." 

Rather than introduce a typecase statement, Leroy and Mauny merge dy- 
namic elimination with the usual case statement of ML. Ignoring this difference, 
their dynamic patterns have the form QZ where Z is a type and Q a list of ex- 
istentially or universally quantified variables. For instance, 

V(X)3(F)V(Y)3(G) (v:T(X,F,Y,G)) 

is a pattern of their system. The existentially quantified variables play the role 
of our pattern variables. The order of quantifiers determines the dependencies 
among quantified variables. Thus, the pattern above can be rephrased: 

3(F)3(G)V(X)V(Y) (v:T(X,F(X),Y,G(X,Y))) 

The equivalent pattern for us is: 

{n, F, G} (v : V(U : n, X, Y) T(X, F(U, X), Y, G(U, X, Y))) 

With the same approach, in fact, we can translate all their patterns. On the 
other hand, some of our patterns do not seem expressible in their language, for 
example: 

{n, F, G} (v : V(U : n, X, Y) T(X, F(U, X), Y, G(U, Y))) 

because the quantifiers in the prefix of their patterns are in linear order, and 
cannot express the "parallel" dependencies of F on X and G on Y. 

Another source of differences is our use of tuple variables. These enable us 
to write examples like the applyTwice function: 
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let applyTwice = 
A(df) A(dxy) 
typecase df of 

{7r,F,F'} (f :V(U:7r)F(U)^F'(U)) 
typecase dxy of 

{^',G,H} (x,y:V(U':^')F(G(U'))x(F(H(U')))) 
f X, f y 
else . . . 
else . . . 

which applies its first argument to each of the two components of its second 
argument and returns the pair of the results. Such examples cannot be expressed 
in systems with only type quantifiers. 



5 Abstract Data Types 

The interaction between the use of Dynamic and abstract data types gives rise 
to a puzzling design issue: should the type tag of a dynamic containing an 
element of an abstract type be matched abstractly or concretely? There are 
good arguments for both choices: 

• Abstract matching protects the identity of "hidden" representation types 
and prevents accidental matches in cases where several abstract types 
happen to have the same representation. 

• On the other hand, transparent matching allows a more permissive style 
of programming, where a dynamically typed value of some abstract type is 
considered to be a value of a different version of "the same" abstract type. 
This fiexibility is critical in many situations. For example, a program may 
create disk files containing dynamic values, which should remain usable 
even after the program is recompiled, or two programs on different ma- 
chines may want to exchange abstract data in the form of dynamically 
typed values. 

By viewing abstract types formally as existential types [17], we can see ex- 
actly where the difference between these two solutions lies, and suggest a gener- 
alization of existential types that supports both. (Existential types can in turn 
be coded using universal types; with this coding, our design for dynamic types 
in the previous sections yields the second solution.) 

To add existential types to the variant of F defined in the previous section, 
we extend the syntax of types and terms as in Figure 3. 
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T ::= ... 

1 3{Z : K) T 


existential types 


a ::= . . . 

1 pack a as T hiding T 
1 open a as [Z , x\ in a 


packing (existential introduction) 
unpacking (existential elimination) 



Figure 3: Extended syntax with existential types 

The typechecking rules for pack and open are: 

S = 3(Z ■.K)T r h a e [R/Z]T 
r h (pack a as 5 hiding R) ^ S 

T \- ae3(Z : K) S Z ^ FV(T) T,Z : K,x : S h b eT 
r h (open a as [Z,x] in &) G T 



(Pack) 



(Open) 



A typical example where an element of an abstract type is packed into a 
Dynamic is: 

let stackpack = 
pack 

push = A(s:IntList) A(i:Int) cons(i)(s), 
pop = A(s:IntList) cdr(s), 
top = A(s:IntList) car(s), 
new = nil 
as 3(X) 

push:X->Int->X, 
pop:X->X, top:X->Int, new:X 
hiding IntList 

in 

open stackpack as [Stack, stackops] in 
let dstack = 
dynamic 

(stackops . push(stackops . new) (5) : Stack) 

in 

typecase dstack of 

(s:Stack) stackops .top(s) 
else 0 

Note that this sort of example depends critically on the use of open type 
tags. As discussed in section 3.3, open tags must be implemented using run- 
time types. The evaluation of pack must construct a value that carries the 
representation type. 
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We have a choice in the evaluation rule for the open expression: 

• We can evaluate the expression open a as [Z, x] in h by replacing the 
representation type variable Z by the actual representation type obtained 
by evaluating a. 

• Alternatively, we can replace Z by a fresh type constant. 

Without Dynamic, the difference between these rules cannot be detected. But 
with Dynamic we get different behaviors. Since both behaviors are desirable, we 
may choose to introduce an extended open form that provides separate names 
for the abstract version and for the transparent version of the representation 
type: 

T \- a e3(Z : K) S Z ^ FV(T) T,Z : K,x : S h [Z/R\b e T 
r h (open a as [R, Z , x] in &) G T 

(Open) 

In the body of h, we can build dynamic values with tags R or Z; a typecase on 
the former could investigate the representation type, while a typecase on the 
latter could not violate the type abstraction. 

Further experience would be useful for understanding the interaction of 
Dynamic and abstract types. 

6 Subtyping 

In simple languages with subtyping (e.g., [4, 8]) it is natural to extend typecase 
to perform a subtype test instead of an exact match. Consider for example the 
expression: 

let dx = dynamic (3 : Nat) 
in 

typecase dx of 
(x:Int) ... 
else . . . 

The first typecase branch is taken: although the tag of dx, Nat, is different 
from Int, we have Nat<Int. 

Unfortunately, this idea runs into difficulties when applied to more complex 
languages. In general, there does not exist a most general instantiation for 
pattern variables when a subtype match is performed. For example, consider the 
pattern V— S-V and the problem of subtype-matching (Int—S-Nat) <(¥—;>¥). Both 
Int— S-Int and Nat— S-Nat are instances of V— S-V and supertypes of Int— S-Nat, but 
they are incomparable. Even when the pattern is covariant there may be no 
most general match. Given a pattern V x V, there may be a type A x B such that 
A and B have no least upper bound, and so there may be no best instantiation 
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K ::= Type 

I Power(A')(T) 



the kind of types 

the kind of subtypes of T 



J ::= K 



I K"^K {n > 0) 

I Power(A'"^A')(^^) 



Figure 4: Extended syntax with subtyping 



for V. This can happen, for example, in a system with bounded quantifiers [7, 9], 
and in systems where the collection of base types does not form an upper semi- 
lattice. Linear patterns (where each pattern variable occurs at most once) avoid 
these problems, but we find linearity too restrictive. 

Therefore, we take an approach different from that found in simple languages 
with subtyping. Our approach works in general and fits well with the language 
described in section 3.2. We intend to extend system F with subtyping along 
the lines of [6]. In order to incorporate also the higher-order pattern variables, 
we resort to power-kinds [5]. 

The kind structure of section 3.2 is extended in Figure 4, where it is assumed 
that T : K and F : K"^K. Informally, the kind Power (Type) (T) is the collec- 
tion of all the subtypes of T, and similarly the kind Power (A'l x . . . K„^K){F) 
is the collection of all the operators of kind A'l x . . . K„ — t- A' that are pointwise 
in the subtype relation with F . Subtyping (<) is not a primitive notion in the 
syntax, but it is defined by interpreting: 

T<T' : A as T : Power(A)(T'), where T, T' : A 
F<G : (Ai X ... X A„^A) as F{Qi, 0„)<G(Oi, . . . , 0„) : A, 
for all Qi : A'l, . . . , Q„ : A'„, where F, G : (A'l x . . . x K„^K) 

The axiomatization of Power(A')(T) [5] is designed to induce the expected sub- 
typing rules. For example, T : Power(T) says that T<T. 

Because of power-kinds, we can now write patterns such as: 

typecase dx of 

{V,¥<(VxV)} (x:¥xV) . . . 

(that is: {V:Type, ¥:Power(Type) (VxV)} (x:¥xV)) 
else . . . 

Each branch guard is used in typechecking the corresponding branch body. 
The shape of branch guards is {Ai : A'l, . . . , F„ : A'„}(a; : P) where each A,- 
may occur in the Kj with j > i and in P. This shape fits within the normal 
format of typing environments, and hence it introduces no new difficulties for 
static typechecking. 
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Next we consider the dynamic semantics of typecase in the presence of 
subtyping. The idea is to preserve the previous notion that typecase performs 
exact type matches at run time. Subtyping is introduced as a sequence of 
additional constraints to be checked at run time only after matching. These 
constraints are easily checked because, by the time they are evaluated, all the 
pattern variables have been fully instantiated. In the example above, suppose 
that the tag of dx is (Nat x Int) x Int; then we have the instantiations ¥ = 
Nat X Int and V = Int. When the matching is completed, we successfully check 
that ¥<(V X V). 

Some examples should illustrate the additional flexibility obtained with sub- 
typing. First we show how to emulate simple monomorphic languages with 
subtyping but without pattern variables, where typecase performs a subtype 
test. The flrst example of this section can be reformulated as: 

typecase dx of 

{V<Int} (x:V) ... 
else . . . 

In this example, the tag of dx can be any subtype of Int. 

The next example is similar to dynApply in section 2, but the type of the 
argument can be any subtype of the domain of the function: 

typecase df of 
{¥,¥} (f:V-^¥) 
typecase da of 
{V'<V} (a:V') 

dynamic(f (a) :¥) 
else . . . 
else . . . 

With polymorphic tag types, or with polymorphic pattern types with only 
flrst-order pattern variables, nothing new happens except that the matching 
and subtype tests must be the adequate ones for polymorphism. 

The next degree of complexity is introduced by higher-order pattern vari- 
ables. Just as we had V'<V, a subtype constraint between two flrst-order pat- 
tern variables, we may have F<G : (K— S-K ' ) for two higher-order pattern variables 
F,G: (K— S-K' ). As mentioned above, the inclusion is intended pointwise: F<G iff 
F(X)<G(X) :K' under the assumption X:K. 

Another form of dynamic application provides an example of higher-order 
matches with subtyping: 

typecase df of 

{F,G:Type-^Type,V} (f : V(Z<V)F(Z)-^G(Z) ) 
typecase da of 

{¥<¥} (a:F(¥)) dynamic(f [¥] (a) :G(¥) ) 
else . . . 
else . . . 
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Finally, dynamic composition calls for a constraint of the form G'<G: 

typecase df of 

{G,H:Type-^Type} (f : V(X)G(X)-^H(X) ) 
typecase dg of 

{F : Type^Type , G ' <G : Type^Type} 

(g:V(Y)F(Y)^G'(Y)) 
dynamic((A(Z) f [Z] o g[Z] ) : V(Z)F(Z)-^H(Z) ) 
else . . . 
else . . . 

This example generalizes to functions of bounded polymorphic types, such as 
V(X<A)G(X)-^H(X). 

7 Conclusion 

The extension of statically-typed languages with dynamic types is rather com- 
plicated. Perhaps we have been overly ambitious. We have tried to allow as 
much flexibility as possible, at the cost of facing difficult matching problems. 
And perhaps we have not been ambitious enough. In particular, we have not 
provided mechanisms for dealing with multiple matches at run time, in order 
not to complicate the language designs or their implementations. We have also 
ignored the possibility of adding dynamic types to Fs, or to F^^ [10]. Only more 
experience will reveal the most useful variants of our approach. 

We have deliberately avoided semantic considerations in this paper. It seems 
relatively straightforward to provide precise operational semantics and then 
prove subject-reduction theorems for our languages. These theorems would 
be extensions of those established for monomorphic languages in [1], and would 
guarantee the soundness of evaluation for the languages. It is an entirely dif- 
ferent matter to deflne denotational semantics. In particular, open tags clearly 
allow the expression of a rich class of non-parametric functions (which manipu- 
late types at run time) , and these do not exist in many of the usual models for 
polymorphic languages. 
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